1. Field of the Invention
The present invention relates to a system and method for performing kernel-mode operations, and in particular to a system and method for performing secure kernel-mode operations, executing a low-level debugging process.
2. Description of the Related Art
Using debugging processes, software engineers are the bridge between software and hardware, determining errors in software, such as BIOS (Basic Input/Output System), drivers, or operating systems, and in hardware.
FIG. 1 is a schematic diagram showing architecture access system resources in a disk operating system (DOS). The architecture comprises application/tool 11, BIOS 13, authorized instruction 15, I/O (Input/Output) port 17 and memory 19. Traditionally, an operating system, such as disk operating system, opens all system resources to users, accessing BIOS 13 or executing low-level operations, performing authorized instruction 15 or accessing I/O port 17 and memory 19, through application/tool 11, none of which create serious problems during debugging.
Currently, operating systems must transit from the traditional CPU (Central Processing Unit) operating mode (real mode herein) to a 32-bit protected mode, providing enhanced operating efficiency and system resource management. Under protected mode, the operating system restricts and prohibits most of system recourses, thus the accessibility of the system resources and operations are available to only those holding the highest authorization, such as Ring 0 authorization.
FIG. 2 is a schematic diagram showing kernel-mode operations performed through a kernel-mode driver in a Windows operating system, comprising application/tool 21, kernel-mode interface driver 23, BIOS 251, authorized instruction 253, I/O port 257 and memory 259. Application/tool 21 and kernel-mode interface driver 23 are executed in a user mode, while BIOS 251, authorized instruction 253, I/O port 257 and memory 259, are stored in a kernel mode. In conventional methods, to obtain Ring 0 authorization, kernel-mode interface driver 23 must be programmed using application/tool 21, via a driver call procedure, to enter kernel mode by performing a system call, directly accessing BIOS 251, or performing low-level operations such as executing authorized instructions 253 or accessing I/O port 257 and memory 259, implemented by driver development kit (DDK) in the Windows operating system.
FIG. 3 shows a schematic diagram performing kernel-mode operations using the driver development kit (DDK). Fundamentally, DDK packages desired data processed in a kernel mode to form an I/O request packet (IRP) 31, and informing a driver by a system call with a function DeviceIoControl( ) with respect to IRQ 31 and control codes. Next, hardware 37, such as authorized instruction 371, I/O port 373 and memory 375, is accessed by I/O management system 33 through a series of transformations to hardware abstraction layer 35, and the procedure is complete.
Such a procedure, however, causes problems with system manufacturing, since, although normal use seeks to implement tasks with simple and intuitive kernel-mode operations, conditions become more complex and varied during system development, such that a specific kernel-mode driver may not be able to handle some situations. In addition, time limitations placed on some operations may affect accuracy. DDK can be difficult to work with, and applications proven in DOS may be difficult to transfer to other system architectures using a kernel-mode driver, requiring revision of software architecture or re-programming of source code.